[CHERIoT] Fix divergence between frontend and backend as to whether CHERIoT counts as EABI. #165
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
At some point, we will want to use capability registers to hold doubles (if we support a variant of Zdinx and possibly for softfloat as well), so we do require 8-byte alignment. |
Collaborator
Author
Changed it so both frontend and backend disable the GCC workaround for Cheriot ABIs. |
rmn30
added a commit
to CHERIoT-Platform/cheriot-rtos
that referenced
this pull request
Jun 6, 2025
See CHERIoT-Platform/llvm-project#165 . This fails with current dev container but should pass once the above PR is merged and a new dev container built.
rmn30
added a commit
to CHERIoT-Platform/cheriot-rtos
that referenced
this pull request
Jun 6, 2025
See CHERIoT-Platform/llvm-project#165 . This fails with current dev container but should pass once the above PR is merged and a new dev container built.
xdoardo
approved these changes
Jun 6, 2025
resistor
force-pushed
the
f64-varargs
branch
2 times, most recently
from
0eaa523 to
0185c6c
Compare
…HERIoT counts as EABI. It was always intended to be treated as such, but when upstream added support for EABI, we missed updating the check in the frontend to handle CHERIoT as well. This manifests as a bug only in one very specific scenario: clang maintains compatibility with non-conforming versions of GCC that do not properly align doubles on the stack when targeting EABI, aligning them instead to 4 bytes. CHERIoT does not specifically care whether or not we are using the GCC-compatible version, but if the frontend and backend disagree on which version we are using, then the caller and callee will end up with incompatible stack layouts. This is because the caller layout is constructed by the backend, while the callee layout is constructed by the frontend.
rmn30
added a commit
to CHERIoT-Platform/cheriot-rtos
that referenced
this pull request
Jun 11, 2025
See CHERIoT-Platform/llvm-project#165 . This fails with current dev container but should pass once the above PR is merged and a new dev container built.
rmn30
added a commit
to CHERIoT-Platform/cheriot-rtos
that referenced
this pull request
Jun 11, 2025
See CHERIoT-Platform/llvm-project#165 . This fails with current dev container but should pass once the above PR is merged and a new dev container built.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It was always intended to be treated as such, but when upstream added support for EABI, we
missed updating the check in the frontend to handle CHERIoT as well.
This manifests as a bug only in one very specific scenario: clang maintains compatibility
with non-conforming versions of GCC that do not properly align doubles on the stack when
targeting EABI, aligning them instead to 4 bytes. CHERIoT does not specifically care whether
or not we are using the GCC-compatible version, but if the frontend and backend disagree
on which version we are using, then the caller and callee will end up with incompatible stack
layouts. This is because the caller layout is constructed by the backend, while the callee
layout is constructed by the frontend.